[EXPERIMENTAL] Slack Lists message field: direction-aware MessageRef - #1637
Draft
zimeg wants to merge 1 commit into
Draft
[EXPERIMENTAL] Slack Lists message field: direction-aware MessageRef#1637zimeg wants to merge 1 commit into
zimeg wants to merge 1 commit into
Conversation
Types ListRecord.Field.message as List<MessageRef> ({value, channel_id, ts,
thread_ts?}) and adds a Gson adapter so one type models the field's asymmetric
wire shape, verified against the live API on two surfaces (slackLists.items.list
and the conversations.history/replies nested list_record path):
- request: each MessageRef serializes to its `value` -> message: ["<permalink>"]
(the API rejects object form: "must provide a string")
- response: deserializes {value, channel_id, ts, thread_ts?} objects, always an
array (no single-object form observed); tolerates bare-string elements too
This supersedes the Message-typed modeling from #1590, whose element type (a
full chat Message) did not match the payload. The now-redundant test
GsonListRecordFieldFactory is removed (default Gson handles List<MessageRef>).
The remote slacklists_Test adds a message column, posts and references a
message, and asserts the echoed reference shape so the generated sample carries
the real message field. Model tests pass (7/7); the remote test passes live.
Fixes the Java half of node-slack-sdk#2598 (node response types generate from
these Java samples). Source-only; the sample regeneration lands via the runner.
Co-Authored-By: Claude <svc-devxp-claude@slack-corp.com>
❌ 28 Tests Failed:
View the top 3 failed test(s) by shortest run time
To view more test analytics, go to the Test Analytics Dashboard |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Types the Slack Lists item
messagefield asList<ListRecord.MessageRef>({value, channel_id, ts, thread_ts?}) and adds a Gson adapter so a single type models the field's asymmetric wire shape in both directions.Verified against the live API on two surfaces —
slackLists.items.listand the nestedlist_recordattachment inconversations.history/conversations.replies:MessageRefserializes to itsvalue→message: ["<permalink>"](the API rejects object form:must provide a string){value, channel_id, ts, thread_ts?}objects — always an array,thread_tsonly for threaded replies; no single-object form observed. Tolerates bare-string elements defensively.Why
The prior modeling (#1590) typed the element as a full chat
Message, which does not match the payload (the real element is a lightweight message reference), and normalized a single-object↔array case the API does not actually return on these endpoints. See field-types.This is the Java half of node-slack-sdk#2598 — node response types generate from these Java samples, so the sample must carry the real shape. It also makes node-slack-sdk#2599 / #2600 obsolete (they modeled
Message | Message[]— wrong element type + an unnecessary union).Changes
ListRecord.Field.message→List<MessageRef>; newListRecord.MessageReftype.GsonListRecordMessageRefFactory(direction-aware), registered in the main + testGsonFactory.GsonListRecordFieldFactory(default Gson handlesList<MessageRef>).slacklists_Test(remote): adds a message column, posts + references a message, asserts the echoed reference shape — so the generated sample carries the real field.Verification
ListRecordFieldTest, incl. request-serialize + response-deserialize).slacklists_Test: passes live (3/3) against the Slack API; raw capture confirms{value, channel_id, ts}.Status — EXPERIMENTAL / breaking
This changes the field's public type (was
Message-based). Flagged experimental for review; not for merge-as-is without a call on the breaking change. The sample regeneration is intentionally left to a controlled runner run (the ad-hoc regen bloatedresponse_metadata.messages— kept out of this source PR).🤖 Generated with Claude Code